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DETAILED ACTION 



1. 



This Office action is in response to the RCE filed on 10/5/10. 



2. 



Claims 1-6, 8, 11-25, 27 and 28 are pending. 



Continued Examination Under 37 CFR 1.114 



3. A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/5/10 
has been entered. 

Information Disclosure Statement 

4. The IDS filed on 10/5/10 has been considered. An initial copy is enclosed. 



5. The instant application is a continuation in part to application 1 065021 1 . The 
parent application does not disclose any embodiments that feature all limitations of each 
of the instant claims. For example, none of a forward proxy, reverse proxy and/or 
transparent proxy are identified as embodiments in the earlier application. Hence, the 



Priority 
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priority date with respect to the prior art for the instant claims of this application is the 
filing date of the instant application. See amended specification filed on 1/21/09. 



Claim Interpretation 

6. With respect to the following limitation of claim 1 ("the remote site delegates data 

vending on behalf of the remote site to be managed and distributed by the local 

managing service from within the local processing environment of the client and the 

local managing service presents itself to the client as the remote site"), the disclosure 

on pg. 7 of Applicant's specification is deemed pertinent: 

Thus, when the proxy 102 detects that a client 101 is attempting to establish secure 
communications with a remote site 120 that is associated with a particular local managing 
service 103, the proxy 102 passes the client 101 request for 10 communication along to 
the particular local managing service 103. The local managing service 103 is trusted by 
the remote site 120, this means that the remote site 120 may house the identity of the 
local managing service 103 in one of its trusted data stores which identifies trusted 
parties. The remote site 120 also recognizes communications with the local managing 
service 103 as being secure. 15 Similarly, the local managing service 103 recognizes and 
trusts the remote site 120. Thus, the remote site 120 delegates its authority to the local 
managing service 103 to vend some of its data on behalf of it within the local networking 
environment of the client 101 . 

One technigue for doing this is to provide a digital certificate of the remote 20 site 120 to 
the local managing service 103. Typically, the remote site 120 provides certificates to 
trusted parties for purposes of decrypting its data communications. The remote site 120 
may also provide an encryption key to the local managing service 103. The encryption 
key is what the remote site 120 personally uses to encrypt its data communications for 
purposes of secure communications with a 25 trusted party. Armed with the certificate 
and/or encryption key, the local managing service 103 can present itself to the client 101 
within the client's local computing environment as if the local managing service 103 were 
in fact the remote site 120. 

Once the proxy 102 and the local managing service 103 are properly configured within 
the client's local computing environment, data can be managed 30 and accelerated by 
the local managing service 103 on behalf of the remote site 120 
in the following manners. 
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7. With respect to the limitation "a local computing environment," the specification 

describes the proxy (reference no. 102) and local service (reference no. 103) depicted 

in fig. 1 as being "within the local computing environment of the client 1 01 ." See pg. 8, 

lines 27-31 and pg. 10, lines 9-15. Fig. 1 depicts the proxy (on a first server device), 

local service (on a second server device) and client (on a laptop) as devices situated 

within a local network environment. Hence, "a local computing environment" as used in 

the claims appears to be analogous to a "local networking environment." On pg. 4 of 

the specification, Applicant provides a description of a "local networking environment," 

which is reprinted here: 

Local networking environment refers to physical or logical network devices and services 
which are configured to be local to the clients and which interface with the clients. This 
does not mean that any particular local networking environment of a particular client 
physically resides in the same geographic location of the client or proximately resides 
within the same geographic location of the client, although in some embodiments this can 
be the case. Local networking environments can be dispersed geographically from the 
physical location of the client and form a logical local networking environment of the 
client. [Emphasis added] 

8. This page of the Specification further discloses that "[a]n external networking 
environment is a network which is not considered local to the client." In view of this 
portion of the specification, a device or service is "within a local computing environment" 
of a client if it forms a logical local networking environment of the client regardless of the 
geographic location of the client and the device or service. In other words, whether a 
device is within the "local computing environment" of the client depends solely on the 
operational relationship between the device and the client. 



Response to Arguments 
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9. Applicant's arguments with respect to the amended claims have been considered 
but are not persuasive. On pgs. 8-9 of Applicant's Remarks, Applicant alleges that the 
combined teachings of Boneh and Aziz does not teach the new limitations ("processing 
a local managing service from within a local computing environment" [see exemplary 
claim 1]), because "Aziz provides a relay that operates and processes on a device and 
an environment that is different from the client and the server." Remarks, pg. 8, last 
paragraph. Applicant points to fig. 5 of Aziz to show that "the relay 560 processes in its 
own independent environment and on its own independent machine." Remarks, pg. 9, 
first paragraph. This argument is not persuasive because the phrase "local computing 
environment" is broadly construed in view of the specification. As discussed above, the 
specification depicts a "local computing environment" as being analogous to a "local 
networking environment," and the specification further explains that the geographic 
distance between a client device and a secondary device does not prevent the two 
devices from being within the same local networking environment: the secondary device 
must merely interface with the client and "form a logical local networking environment of 
the client." See pg. 4. In the case of Aziz, the relay clearly interfaces with the client and 
functions as a logical local networking environment of the client in view of the fact that 
the client maintains a trust relationship with the relay (see col. 6, lines 58-60 ["All of the 
information sent from a client is decrypted by the relay."]) and the client establishes a 
secure connection with the remote service via the relay (see col. 5, lines 34-41 ). It is 
further noted that fig. 5 of Aziz is not the only embodiment as implied by applicant's 
arguments, but merely one embodiment envisioned by the inventor (see col. 6, lines 6- 
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10, "For example, as illustrated in Fig. 5, clients 200, 300 and 400 could each be a client 
computer 500, server computers 240, 340, and 470 could each be a server computer 
530, and relay computers 220, 320 and 440 could each be relay computer 560.") 

1 0. Furthermore, even assuming arguendo that the relay of Aziz was not a logical 
local network environment of the client, this distinction does not undermine the 
obviousness rejection in view of Boneh and Aziz. As outlined below, the proxy server 
disclosed in Boneh is part of the local computing environment of the client. See fig. 4. 
As articulated in the rejections below, one of ordinary skill in the art would recognize 
that an obvious modification of Boneh with the teachings of Aziz would be to implement 
a reverse proxy on behalf of the remote service in place of the proxy defined in Boneh, 
where the reverse proxy would use the remote service certificate to act on behalf of the 
remote service. Hence, regardless of the merits of applicant's arguments about the 
relay of Aziz, the combined teachings of Boneh and Aziz suggest a local managing 
service from within a local computing environment of the client acting as a reverse proxy 
on behalf of the remote site. For these reasons, the amended claims remain rejected 
under the prior art of record. 

Double Patenting 

1 1 . The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. A nonstatutory 
obviousness-type double patenting rejection is appropriate where the conflicting claims 
are not identical, but at least one examined application claim is not patentably distinct 
from the reference claim(s) because the examined application claim is either anticipated 
by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 
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F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 
1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 
F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1 .321 (c) or 1 .321 (d) 
may be used to overcome an actual or provisional rejection based on a nonstatutory 
double patenting ground provided the conflicting application or patent either is shown to 
be commonly owned with this application, or claims an invention made as a result of 
activities undertaken within the scope of a joint research agreement. 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 



12. Claims 1-6, 8, 10-25, 27 and 28 are provisionally rejected on the ground of 
nonstatutory obviousness-type double patenting as being unpatentable over claims 1, 3- 
15, 17-22 and 24-26 of copending Application No. 10814983. Although the conflicting 
claims are not identical, they are not patentably distinct from each other because the 
claimed method and system for managing and accelerating the delivery of data as 
defined in the instant claims are substantially defined in claims 1, 3-15, 17-22 and 24-26 
of copending Application No. 10814983. 

This is a provisional obviousness-type double patenting rejection because the 
conflicting claims have not in fact been patented. 



Claim Rejections - 35 USC § 103 

1 3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
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invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

14. Claims 1-6, 8, 11-25, 27 and 28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Boneh et al. US 20040015725 (hereinafter Boneh) in view of Aziz et 
al. US 6,643,701 (hereinafter Aziz). 

15. As per claims 1-6, Boneh discloses a method for managing and accelerating the 
delivery of data implemented in a computer-readable storage medium and processed 
on a proxy device for performing the method, comprising: 

a. receiving a secure communications request for data associated with a 
remote site, wherein the request is received from a client and the secure 
communications request occurs via Secure Socket Layer (SSL) communications 
with the client (paragraph 26) and wherein the request is received at a forward 
proxy that processes within a local processing environment of the client (fig. 4; 
paragraph 36, browser first sends a message CONNECT www.xyz.com to the 
web proxy; compare with paragraph 47, where no CONNECT messages is pre- 
appended); 

b. processing a local managing service from within a local computing 
environment of the client (see fig. 4, the proxy server is situated locally with the 
client and forms a logical local networking environment of the client) 

c. passing the request to the local managing service for processing acting as 
the forward proxy for the client, wherein the local managing service is capable of 
caching the data for servicing the secure communications request of the client 
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within the local processing environment of the client and capable of securely 
interfacing with the remote site (paragraphs 34-42; client sends the connect 
request message to the web proxy; proxy performs caching on decrypted 
response); 

d. the local managing service houses an identity for the remote site and local 
managing service is trusted by the remote site and the remote site delegates 
authority to the local managing service to vend data of the remote sites within the 
local processing environment of the client (paragraphs 37 and 41 , web proxy 
creates a TLS session to the site www.xyz.com ; TLS session establishment 
entails certificate exchange and verification between the web proxy and the 
remote site; see also pg. 7, lines 13-18 of the instant specification); 

e. creating, by the local proxy device, a secure communications tunnel 
between the client and the local managing service (paragraph 40, TLS session 
between the client and the web proxy; see for example paragraph 12 for TLS 
session generation); and 

f. creating, by the proxy device, another secure communications tunnel 
between the local managing service and the remote site (paragraph 41 , web 
proxy creates a TLS session with the site www.x yz.com ); 

g. determining, by the local managing service, when the secure 
communications request can be satisfied with cached data; and supplying the 
data from the cached data to the client with secure communications, when 
present in cache; requesting, by the local managing service, the data from the 
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remote site if the data is not in the cache; receiving the data from the remote site; 
and supplying the data to the client with secure communications; housing the 
data in the cache for subsequent requests made by the client or other clients for 
the data, when the data is permitted to be cached (paragraph 42, all features are 
inherent in caching services); 

h. maintaining, by the local managing service, a certificate associated with 
communications from the remote site (paragraph 41); 

i. transmitting, by the local managing service, to the remote site a first 
certificate associated with the identity of the local managing service; 
receiving, from the remote site, at the local managing service a second certificate 
associated with the identity of the remote site; and communicating between the 
remote site and the local managing service with Secure Sockets Layer (SSL) 
communications using the first and second certificates (paragraph 41). 

16. Furthermore Boneh discloses that the web proxy presents itself to the client as 
the remote site by generating a server certificate at the web proxy and communicating 
the certificate to the user client. Secure communications between the client and the 
web proxy is established using the key inserted into the certificate (paragraph 45, "the 
browser is configured to accept this proxy-server certificate, the web proxy successfully 
binds the destination server name (www.xyz.com) to the proxy-generated proxy session 
public key, allowing the proxy to thereafter masquerade as the destination server 
www.xyz.com") 
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1 7. Boneh does not expressly disclose that the local service acts as a reverse proxy 
on behalf of the remote site from the local processing environment of the client, 
whereby the remote site delegates data vending on behalf of the remote site to be 
managed and distributed by the local managing service from within the local processing 
environment of the client. Aziz discloses a method and apparatus for providing secure 
communications between a client and a server. When the client desires to establish a 
secure connection with the remote server, a first secure communication is established 
between the client and a relay, and a second secure communication is then established 
between the relay and the server. In particular, on col. 5, lines 1-22 and col. 8, lines 13- 
32, Aziz discloses 

Information stored on relay 220 is used to create the secure connection. 
When a server wishes to obtain advantages of the present invention in a 
manner that could be transparent to client 200, server 240 will have a trust 
relationship with (that is, be controlled by or even be owned by the same 
entity as) relay 220. Therefore, server 240 will share its private key and 
certificate with relay 220 . When a client wishes to obtain advantages of 
the present invention in a manner that could be transparent to server 240, 
client 200 will have a trust relationship with relay 220, and client 200 will, 
e.g., accept the certificate of relay 220 as that of server 240 and provide 
an authentication token of client 200 to relay 220. Thereby, relay 220 may 
be inserted without access to the server's keys. This architecture could, 
for example, assist a programmer in diagnosing problems with a client's 
application that communicates with an HTTPS server (by convention a 
secure server address is given the prefix "https://") even when the server 
would not provide the programmer with access to the server's keys. When 
both client 200 and server 240 wish to achieve the advantages of the 
present invention in a manner known to each entity, each will provide 
appropriate information to relay 220 . ... 

...Because relays 320 are trusted by server 340, server 340 provides each 
relay 320 with its security certificate and with its public and private key pair 
for use in an encryption/decryption process (step 910). Either prior to 
during, or in response to a client request for information from server 340, 
the secure connection program of relay 320 and the secure connection 
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program of server 340 create an end-to-end security link 330 using a 
handshaking session (step 920). For example, using SSL, this link is 
established following a handshaking session similar to that described with 
regard to FIG. 1. For enhanced security, each end point (relay and 
server) authenticates one another using the relay's certificate and 
private/public key pair and the server's certificate and private/public key 
pair. The secure connection program of relay 320 and the secure 
connection program of server 340 could also create link 330 following a 
refresh handshaking session that occurs after an initial handshaking 
session. The refresh handshaking session could occur at a 
predetermined period based on an elapse of a predetermined time, 
transfer of a predetermined amount of information, etc. to provide 
replacement session keys and, thus, increased security. 



18. It would be obvious to one of ordinary skill in the art at the time the invention was 
made to modify the invention of Boneh such that that the local service acts as a reverse 
proxy on behalf of the remote site from the local processing environment of the client, 
whereby the remote site delegates data vending on behalf of the remote site to be 
managed and distributed by the local managing service from within the local processing 
environment of the client. One would be motivated to do so to avoid performing 
intensive processing tasks such as generating private keys and digital certificates at a 
network juncture as known to one of ordinary skill in the art. The aforementioned cover 
the limitations of claims 1 -6. 



1 9. As per claims 8 and 11-15, Boneh discloses a method of managing and 
accelerating delivery of data implemented in a computer-readable storage medium and 
to process within a local networking environment of a client for performing the method, 
comprising: 
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j. processing a local service of a proxy for communicating securely with the 
client and for acting on behalf of the client during interactions between the client 
and a remote site (fig. 4), wherein the local service processes from within a local 
computing environment of the client and uses Secure Socket Layer (SSL) 
communications when interacting with the client (paragraph 26); managing 
authority from the remote site at the local service and within the local computing 
environment of the client (see fig. 4, the proxy server is situated locally with the 
client and forms a logical local networking environment of the client; paragraphs 
37 and 49); 

k. establishing a secure tunnel between the local service of the proxy and 

the client for interactions between the client and the local service (paragraph 51 , 

secure TLS session between the client and the web proxy); 

I. establishing another secure tunnel between the local service and the 

remote site for interactions between the local service and the remote site 

(paragraph 53, secure TLS session between the web proxy and the remote site); 

and 

m. caching, within the local service, data received from the remote site, and 
wherein portions of the data are sent to the client in order to service data 
requests made from the client to the remote site (paragraphs 46-54); 
n. initially transmitting a local service certificate to the remote site; and 
subsequently communicating securely between the local service and the remote 
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site using the local service certificate and the certificate of the remote site 
(paragraph 53); 

o. establishing the proxy as a transparent proxy for the client (paragraph 47); 
p. inspecting at the proxy a secure request made from the client for the 
remote site; and transferring the secure request to the local service for 
processing (paragraph 52); 

q. wherein caching further includes housing the data in a decrypted format 
within cache of the local service (paragraph 54, caching services are performed 
on decrypted response); 

r. wherein caching further includes sending the portions of the data from the 
cache to the client along with the certificate associated with the remote site 
(paragraph 49 and 54 [cache services]). 

20. Furthermore Boneh discloses that the web proxy presents itself to the client as 
the remote site by generating a server certificate at the web proxy and communicating 
the certificate to the user client. Secure communications between the client and the 
web proxy is established using the key inserted into the certificate (paragraph 45, "the 
browser is configured to accept this proxy-server certificate, the web proxy successfully 
binds the destination server name (www.xyz.com) to the proxy-generated proxy session 
public key, allowing the proxy to thereafter masquerade as the destination server 
www.xyz.com") 

21 . Boneh does not expressly disclose that the local service acts as a reverse proxy 
on behalf of the remote site from the local computing environment of the client, whereby 
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the remote site delegates data vending on behalf of the remote site to be managed and 
distributed by the local managing service from within the local processing environment 
of the client; and that the authority is managed by accessing a certificate of the remote 
site at the local service. Aziz discloses a method and apparatus for providing secure 
communications between a client and a server. When the client desires to establish a 
secure connection with the remote server, a first secure communication is established 
between the client and a relay, and a second secure communication is then established 
between the relay and the server. In particular, on col. 5, lines 1-22 and col. 8, lines 13- 
32, Aziz discloses 

Information stored on relay 220 is used to create the secure connection. 
When a server wishes to obtain advantages of the present invention in a 
manner that could be transparent to client 200, server 240 will have a trust 
relationship with (that is. be controlled bv or even be owned bv the same 
entity as) relay 220. Therefore, server 240 will share its private key and 
certificate with relay 220 . When a client wishes to obtain advantages of 
the present invention in a manner that could be transparent to server 240, 
client 200 will have a trust relationship with relay 220, and client 200 will, 
e.g., accept the certificate of relay 220 as that of server 240 and provide 
an authentication token of client 200 to relay 220. Thereby, relay 220 may 
be inserted without access to the server's keys. This architecture could, 
for example, assist a programmer in diagnosing problems with a client's 
application that communicates with an HTTPS server (by convention a 
secure server address is given the prefix "https://") even when the server 
would not provide the programmer with access to the server's keys. When 
both client 200 and server 240 wish to achieve the advantages of the 
present invention in a manner known to each entity, each will provide 
appropriate information to relay 220 . ... 

...Because relays 320 are trusted by server 340, server 340 provides each 
relay 320 with its security certificate and with its public and private key pair 
for use in an encryption/decryption process (step 910). Either prior to 
during, or in response to a client request for information from server 340, 
the secure connection program of relay 320 and the secure connection 
program of server 340 create an end-to-end security link 330 using a 
handshaking session (step 920). For example, using SSL, this link is 
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established following a handshaking session similar to that described with 
regard to FIG. 1. For enhanced security, each end point (relay and 
server) authenticates one another using the relay's certificate and 
private/public key pair and the server's certificate and private/public key 
pair. The secure connection program of relay 320 and the secure 
connection program of server 340 could also create link 330 following a 
refresh handshaking session that occurs after an initial handshaking 
session. The refresh handshaking session could occur at a 
predetermined period based on an elapse of a predetermined time, 
transfer of a predetermined amount of information, etc. to provide 
replacement session keys and, thus, increased security. 



22. It would be obvious to one of ordinary skill in the art at the time the invention was 
made to modify the invention of Boneh such that the web proxy acts as a reverse proxy 
on behalf of the remote site from the local computing environment of the client, whereby 
the remote site delegates data vending on behalf of the remote site to be managed and 
distributed by the local managing service from within the local processing environment 
of the client; and that the authority is managed by accessing a certificate of the remote 
site at the local service. One would be motivated to do so to avoid performing intensive 
processing tasks such as generating private keys and digital certificates at a network 
juncture as known to one of ordinary skill in the art. The aforementioned cover the 
limitations of claims 8 and 11-15. 



23. As per claim 16-22, Boneh discloses a data management and acceleration 
delivery system implemented in computer-readable storage media and to process on 
devices of a network, the system comprising: 

s. a proxy; a local service accessible to the proxy; and a remote site external 
to the proxy, wherein the proxy directs secure requests received from a client for 
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the remote site to the local service (fig. 4), the local service: acts as a transparent 
proxy on behalf of the client, processes within a local computing environment of 
the client (reference no. 352, the proxy server is situated locally with the client 
and forms a logical local networking environment of the client), and 
communicates securely with the client using Secure Socket Layer (SSL) 
communications (paragraph 26) via a first secure tunnel established by the proxy 
for interactions between the local service and the client, and the local service 
interacts securely with the remote site via a second secure tunnel established by 
the proxy for interactions between the local service and the remote site, the 
interactions between the local service and the remote site is to acquire data on 
behalf of the client, and wherein portions or all of the acquired data are cached 
within the local service and used to service requests made by the client from 
within the local computing environment of the client (paragraphs 46-54; in 
particular, in paragraph 51 , secure TLS session between the client and the web 
proxy is established, and in paragraph 53, secure TLS session between the web 
proxy and the remote site is established); 

t. wherein the local service includes a certificate with an identity of the 
remote site which is vended to the client (paragraphs 37 and 49); 
u. wherein the local service and remote site mutually interact securely with 
one another by exchanging certificates with one another (paragraph 53); 
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v. wherein the local service and the remote site sign communications 
occurring between them (in SSL client authentication and key exchange is 
performed via signature); 

w. wherein the client is a browser application (paragraph 46); 

x. wherein the browser is configured to contact the proxy when making 

requests directed to the remote site (paragraph 48); 

y. wherein the proxy intercepts requests made from the browser which are 
directed to the remote site and forwards the requests to the local service for 
handling the requests (paragraph 46). 

24. Furthermore Boneh discloses that the web proxy presents itself to the client as 
the remote site by generating a server certificate at the web proxy and communicating 
the certificate to the user client. Secure communications between the client and the 
web proxy is established using the key inserted into the certificate (paragraph 45, "the 
browser is configured to accept this proxy-server certificate, the web proxy successfully 
binds the destination server name (www.xyz.com) to the proxy-generated proxy session 
public key, allowing the proxy to thereafter masquerade as the destination server 
www.xyz.com") 

25. Boneh does not expressly disclose that the local service is also configured for 
acting as a reverse proxy on behalf of the remote site from the local computing 
environment of the client, whereby the remote site delegates data vending on behalf of 
the remote site to be managed and distributed by the local managing service from within 
the local processing environment of the client. Aziz discloses a method and apparatus 
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for providing secure communications between a client and a server. When the client 

desires to establish a secure connection with the remote server, a first secure 

communication is established between the client and a relay, and a second secure 

communication is then established between the relay and the server. In particular, on 

col. 5, lines 1-22 and col. 8, lines 13-32, Aziz discloses 

Information stored on relay 220 is used to create the secure connection. 
When a server wishes to obtain advantages of the present invention in a 
manner that could be transparent to client 200, server 240 will have a trust 
relationship with (that is, be controlled by or even be owned by the same 
entity as) relay 220. Therefore, server 240 will share its private key and 
certificate with relay 220 . When a client wishes to obtain advantages of 
the present invention in a manner that could be transparent to server 240, 
client 200 will have a trust relationship with relay 220, and client 200 will, 
e.g., accept the certificate of relay 220 as that of server 240 and provide 
an authentication token of client 200 to relay 220. Thereby, relay 220 may 
be inserted without access to the server's keys. This architecture could, 
for example, assist a programmer in diagnosing problems with a client's 
application that communicates with an HTTPS server (by convention a 
secure server address is given the prefix "https://") even when the server 
would not provide the programmer with access to the server's keys. When 
both client 200 and server 240 wish to achieve the advantages of the 
present invention in a manner known to each entity, each will provide 
appropriate information to relay 220 . ... 

...Because relays 320 are trusted by server 340, server 340 provides each 
relay 320 with its security certificate and with its public and private key pair 
for use in an encryption/decryption process (step 910). Either prior to 
during, or in response to a client request for information from server 340, 
the secure connection program of relay 320 and the secure connection 
program of server 340 create an end-to-end security link 330 using a 
handshaking session (step 920). For example, using SSL, this link is 
established following a handshaking session similar to that described with 
regard to FIG. 1. For enhanced security, each end point (relay and 
server) authenticates one another using the relay's certificate and 
private/public key pair and the server's certificate and private/public key 
pair. The secure connection program of relay 320 and the secure 
connection program of server 340 could also create link 330 following a 
refresh handshaking session that occurs after an initial handshaking 
session. The refresh handshaking session could occur at a 
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predetermined period based on an elapse of a predetermined time, 
transfer of a predetermined amount of information, etc. to provide 
replacement session keys and, thus, increased security. 

26. It would be obvious to one of ordinary skill in the art at the time the invention was 
made to modify the invention of Boneh such that that the local service is also configured 
to act as a reverse proxy on behalf of the remote site from the local computing 
environment of the client, whereby the remote site delegates data vending on behalf of 
the remote site to be managed and distributed by the local managing service from within 
the local processing environment of the client. One would be motivated to do so to 
avoid performing intensive processing tasks such as generating private keys and digital 
certificates at a network juncture as known to one of ordinary skill in the art. The 
aforementioned cover the limitations of claims 16-22. 

27. As per claims 23-25, 27 and 28, Boneh discloses a data management and 
acceleration delivery system implemented in a computer-readable storage medium and 
to process on one or more devices of a network, the system comprising: 

z. a proxy; and one or more local services directly accessible to the proxy, 
wherein the proxy acts as an intermediary between one or more clients and one 
or more remote sites (fig. 4), the proxy detects attempts made by the clients for 
establishing secure communications with the remote sites and based on the 
identities of a particular client and particular remote site identifies a particular 
local service, the particular local service: communicates securely with the 
particular client via Secure Socket Layer (SSL) (paragraph 26) communications 



Application/Control Number: 10/784,440 Page 21 

Art Unit: 2432 

as a transparent proxy to the particular client and via a first tunnel established by 
the proxy between the particular local service and the particular client, the 
particular local service processes within a local computing environment of the 
particular client, and the particular local service also securely communicates with 
the particular remote site via a second tunnel established by the proxy between 
the particular local service and the particular remote site, and wherein the 
particular local service caches data received from the particular remote site for 
purposes of servicing requests for portions of that data requested by the 
particular client and the cached data resides within the local computing 
environment of the particular client (paragraphs 46-54; in particular, in paragraph 
51 , secure TLS session between the client and the web proxy is established, and 
in paragraph 53, secure TLS session between the web proxy and the remote site 
is established; fig. 4, reference no. 352, the proxy server is situated locally with 
the client and forms a logical local networking environment of the client); 
aa. wherein each local service is associated with a unique one of the remote 
sites (paragraph 31 ); 

bb. further comprising switching logic that intercepts requests from the clients 
which are directed to the remote sites and forwards them to the proxy (paragraph 
46); 

cc. wherein each of the local services includes a certificate associated with a 
unique one of the remote sites; wherein a number of the local services 
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communicates securely with a number of the remote sites by initially exchanging 
mutual certificates (the invention operates via SSL or TLS). 

28. Furthermore Boneh discloses that the web proxy presents itself to the client as 
the remote site by generating a server certificate at the web proxy and communicating 
the certificate to the user client. Secure communications between the client and the 
web proxy is established using the key inserted into the certificate (paragraph 45, "the 
browser is configured to accept this proxy-server certificate, the web proxy successfully 
binds the destination server name (www.xyz.com) to the proxy-generated proxy session 
public key, allowing the proxy to thereafter masquerade as the destination server 
www.xyz.com") 

29. Boneh does not expressly disclose that the particular local service acts as a 

reverse proxy on behalf of the remote site from the local computing environment of the 

client, whereby the remote site delegates data vending on behalf of the remote site to 

be managed and distributed by the local managing service from within the local 

processing environment of the client. Aziz discloses a method and apparatus for 

providing secure communications between a client and a server. When the client 

desires to establish a secure connection with the remote server, a first secure 

communication is established between the client and a relay, and a second secure 

communication is then established between the relay and the server. In particular, on 

col. 5, lines 1-22 and col. 8, lines 13-32, Aziz discloses 

Information stored on relay 220 is used to create the secure connection. 
When a server wishes to obtain advantages of the present invention in a 
manner that could be transparent to client 200, server 240 will have a trust 
relationship with (that is, be controlled by or even be owned by the same 
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entity as) relay 220. Therefore, server 240 will share its private key and 
certificate with relay 220 . When a client wishes to obtain advantages of 
the present invention in a manner that could be transparent to server 240, 
client 200 will have a trust relationship with relay 220, and client 200 will, 
e.g., accept the certificate of relay 220 as that of server 240 and provide 
an authentication token of client 200 to relay 220. Thereby, relay 220 may 
be inserted without access to the server's keys. This architecture could, 
for example, assist a programmer in diagnosing problems with a client's 
application that communicates with an HTTPS server (by convention a 
secure server address is given the prefix "https://") even when the server 
would not provide the programmer with access to the server's keys. When 
both client 200 and server 240 wish to achieve the advantages of the 
present invention in a manner known to each entity, each will provide 
appropriate information to relay 220. ... 

...Because relays 320 are trusted by server 340, server 340 provides each 
relay 320 with its security certificate and with its public and private key pair 
for use in an encryption/decryption process (step 910). Either prior to 
during, or in response to a client request for information from server 340, 
the secure connection program of relay 320 and the secure connection 
program of server 340 create an end-to-end security link 330 using a 
handshaking session (step 920). For example, using SSL, this link is 
established following a handshaking session similar to that described with 
regard to FIG. 1. For enhanced security, each end point (relay and 
server) authenticates one another using the relay's certificate and 
private/public key pair and the server's certificate and private/public key 
pair. The secure connection program of relay 320 and the secure 
connection program of server 340 could also create link 330 following a 
refresh handshaking session that occurs after an initial handshaking 
session. The refresh handshaking session could occur at a 
predetermined period based on an elapse of a predetermined time, 
transfer of a predetermined amount of information, etc. to provide 
replacement session keys and, thus, increased security. 



30. It would be obvious to one of ordinary skill in the art at the time the invention was 
made to modify the invention of Boneh such that that the particular local service acts as 
a reverse proxy on behalf of the remote site from the local computing environment of 
the client, whereby the remote site delegates data vending on behalf of the remote site 
to be managed and distributed by the local managing service from within the local 
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processing environment of the client. One would be motivated to do so to avoid 
performing intensive processing tasks such as generating private keys and digital 
certificates at a network juncture as known to one of ordinary skill in the art. The 
aforementioned cover the limitations of claims 23-25, 27 and 28. 



Conclusion 

31 . The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

32. Bellwood et al. US 6,584,567 discloses a proxy establishing a secure 
communication between a client and a set of servers and further providing caching 
services. 

33. Chawla et al. US 7,137,143 discloses a secure reverse proxy establishing 
separate secure connections between a client and a web server and further providing 
caching services. 

34. "Secures Sockets Layer Discussion List FAQ v1 .1 .1 ," pg. 7 (entered 9/1 7/08) 
discloses establishing separate secure connections between a client and a Netscape 
Proxy server and between a Netscape Proxy server and an external server. 

35. Ackaouy et al. US 7,552,223 disclose a method and system to provide active 
data from one or more storage servers to one or more clients by situating a proxy cache 
between the client and the storage servers. The proxy cache can be configured as 
either a forward proxy or reverse proxy. See col. 3, lines 32-38. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to JUNG KIM whose telephone number is (571)272-3804. 
The examiner can normally be reached on FLEX. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Gilberto Barron can be reached on 571-272-3799. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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